Proxy Pattern 



the “real” thing 


Subprime Credit Card 


1234 5678 9012 1 

14/10 

As c ukerB o r n vrym i n u t e 


proxy for the “real” thing 
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Proxy Pattern 

Design intent: 

"provide a surrogate or 
placeholder for another 
object to control access to 
it" 
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Proxy Structure 














Proxy Example 

«interface» 

Payment 


ZX 

i 

i 

i- 

i 

i 


Cash 


4 


both Cash and 
DebitCard are 
forms of payment 


i 

i 

i 
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Motivation 


Use: 

defer the full cost of creation and initialization of an object 
until we actually need to use it 

• e.g., large image object and a proxy image 
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Virtual Proxy Example 


full data is 
loaded only if 
needed 

r 

i 

i 


«i interface » 
Graphic 


+bounds(): Box 
+draw() 

ZT~ 

i 

i 


proxy represents 
expensive to 
create object 


i 

i 

i 


Reallmage 

< - 

Proxy Image 

+bounds(): Box 
+draw() 


+bounds(): Box 
+draw() 
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Remote Proxy Example 



r 

i 

i 


proxy is a local 
object that 
represents the 
remote object 

~ i 
i 
i 


RemoteObject 

< - 

LocalObject 


















Caching Proxy Example 



r 

i 

i 


proxy is a locally 
cached version of 
the actual remote 
content 

~ i 
i 
i 


RemoteWebPage 

< - 

CachedWebPage 
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Facade Pattern 


101 



State Pattern 
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Problem 


How to code a state model? 

Example: 

simple pop vending machine (single product) 
insert loonie, press dispense button, get a pop 
could eject to return money 
machine has a limited supply 


Simple Pop Machine State Model 



effects (system actions): 

- doReturnMoney 

- doReleaseProduct 
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Pop Machine Class 


public class PopMachine { 

public PopMachine( int count ) { 

} 


77nanaie user events“ 
public void insertLoonie () { 

} 

public void returnMoney() { 

} 

public void dispense() { 

} 
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Attempt 1 

public class PopMachine { // constants for states 


// all potential states 

private final static int START = 0; 
private final static int HAS_ONE_LOONIE = 1; 
private final static int OUT_OF_STOCK = 2; 


private int currentState; 
private int count; 

public PopMachine( int count ) { 

if (count > 0) { 

currentState = START; 
this.count = count; 

} else { 

currentState = OUT_OF_STOCK; 
this.count = 0; 

} 

} 
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Attempt 1 

// handle insert loonie trigger 

public void insertLoonie () { 

if (currentState == START) { 

System.out.printin( 

"loonie inserted" 

); 

currentState = HAS_ONE_LOONIE; 

} else if (currentState == HAS_ONE_LOONIE) { 

System.out.printin( 

"already have one loonie" 

); 

} else if (currentState == OUT_OF_STOCK) { 
System.out.printin( 

"machine out of stock" 

); 

} 

} 
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Attempt 2 

// type-safe enumeration idiom (Joshua Bloch) 

final class State { // singleton objects for states 
private State () {} 


// all 

potential pop 

machine 

states 

// as singletons 




public 

final static 

State 

START = 

new 

State (); 




public 

final static 

State 

HAS. 

_ONE_LOONIE = 

new 

State (); 




public 

final static 

State 

OUT 

_OF_STOCK = 

new 

State (); 





} 
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Attempt 2 


public class PopMachine { 

private State currentState; 
private int count; 


public PopMachine( int count ) { 

if (count > 0) { 

currentState = State.START; 
this.count = count; 

} else { 

currentState = State.OUT_OF_STOCK; 

this.count = 0; 


} 


} 
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Attempt 3 

// using Java 5 enum 

enum State { 

START, 

HAS_ONE_LOONIE, 

OUT_OF_STOCK 

} 
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Attempt 3 

public class PopMachine { // same code as before 

private State currentState; 
private int count; 


public 

if 

PopMachine( int count ) { 

(count > 0) { 

currentState = State.START; 


this.count = count; 
} else { 


} 

} 

currentState = State.OUT_OF_STOCK; 
this.count = 0; 


ill 



Attempt 3 

// handle insert loonie trigger 
public void insertLoonie () { 

- if (burrgTTrs"rarb == siat e. start) —{- 

System.out.printIn( 

"loonie inserted" 

); 

currentState = State.HAS_ONE_LOONIE; 

} else if (currentState == 

State7HAS 0NE L00NIE) { 

System.out.printin( 

"already have one loonie" 

); 

} else if (currentState == 

State.OUT_OF_STOCK) { 

System.out.println( 

"machine out of stock" 

); 

} 
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// handle eject money trigger 
public void ejectMoneyO { 

if (currentState == State.START) { 
System.out.printin ( 

"no money to return" 

) ; 

} else if (currentState == 

- 3 La Le . IIA - g^ettE — &Oe-N^ - E1 — f - 

System.out.printin( 

"returning money" 

) ; 

doReturnMoney() ; 
currentState = State.START; 

} else if (currentState == 

State.OUT_OF_STOCK) { 
System.out.printin( 

"no money to return" 

) ; 

} 

} 
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// handle dispense trigger 
public void dispense() { 

if (currentState == State.START) { 
System.out.printin( 

"payment required" 

); 

} else if (currentState == 

State.HAS_ONE_LOONIE) { 

System.out.printin( 

“‘'releasing product" 


doReleaseProduct (); 
if (count > 0) { 

currentState = State.START; 

} else { 

currentState = State.OUT_OF_STOCK; 

} 

} else if (currentState == 

State.OUT_OF_STOCK) { 

System.out.printin( 

"machine out of stock" 

); 

} 

} 
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// machine actions 



// return inserted money 
private void doReturnMoney() { 

} 


// release one pop 

private void doReleaseProduct() { 

count — ; 

} 


} // class PopMachine 
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Example Use and Output 


public static void main( String[] args ) { 


PopMachine popMachine = new PopMachine( 10 ) ; 


// usual scenario 

popMachine . insertLoonie () ; loonie inserted 

popMachine . dispense () ; releasing product 


// no money, no sale 

popMachine. dispense (); payment required 


// money returned, no sale 
popMachine.insertLoonie(); 
popMachine.ejectMoney() ; 
popMachine.dispense() ; 


loonie inserted 
returning money 
payment required 


} 
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Change Request 

Suppose: 

pop machine now requires payment of two loonies 
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What Needs to Change? 
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Change Request 

Code changes: 

need to change every trigger handling method to check for 
this new state 


also add and adjust transitions 


// add to insertLoonie, ejectMoney, dispense 
// methods 

if (currentState == State.HAS_TWO_LOONIES) { 

} 
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Poor Design 

Potential problems to address / refactor: 
blob class 

• gets increasingly larger over time 
long methods 

• forced to add cases to existing methods 

• could forget a case or introduce bugs 
conditional complexity 

• large conditional logic blocks 
passive data 

• state values not very "object-oriented" 


State Pattern Approach 

C // common interface for pop machine state classes 
interface State { 


what if a 7/7 
new trigger P l 
is added? 


all potential triggers 

blic void insertLoonie ( PopMachine popMachine ) ; 
public void ejectMoney( PopMachine popMachine ); 
public void dispense ( PopMachine popMachine ) ; 


} 


redesign using state design pattern (state objects) 
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Pop Machine States 


«i interface » 
State 


+insertLoonie( ... ) 
+ejectMoney( ... ) 
+dispense( ... ) 


l-T-1 

■ i i 

■ i i 


StartState 


HasOneLoonieState 


OutOfStockState 

+insertLoonie( ... ) 
+ejectMoney( ... ) 
+dispense( ... ) 


+insertLoonie( ... ) 
+ejectMoney( ... ) 
+dispense(... ) 


+insertLoonie( ... ) 
+ejectMoney( ... ) 
+dispense( ... ) 
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0 class StartState implements State { 



public void msertLoome ( PopMachme popMachine ) { 

System.out.printIn( "loonie inserted" ); 

popMachine.setState( 

popMachine.getHasOneLoonieState() 

); 

public void ejectMoney( PopMachine popMachine ) { 

_ i nt-ln ( "no money to rptnrn" ): _ 

} 

public void dispense( PopMachine popMachine ) { 

System.out.printin( "payment required" ); 

} 


s 


\ 


Start 


\ 
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class HasOneLoonieState implements State { 



public void insertLoonie ( PopMachine popMachine ) { 

System.out.printIn( "already have one loonie" ); 

} 


public void ejectMoney( PopMachine popMachine ) { 

System.out.printIn( "returning money" ); 

popMachine.doReturnMoney() ; 
popMachine.setState( 

popMachine.getStartState() 

); 


/-\ 

Has One 
Loonie 

v_ J 
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0 // class HasOneLoonieState continued 



public void dispense ( PopMachine popMachine ) { 

System.out.printin( "releasing product" ); 

popMachine.doReleaseProduct(); 
if (popMachine.getCount() > 0) { 

popMachine.setState( 

popMachine.getStartState() 

); 

} else { 

popMachine.setState( 

popMachine.getOutOfStockState() 

); 

} 

} 
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class OutOfStockState implements State { 



public void insertLoonie( PopMachine popMachine ) { 

System.out.printIn( "machine out of stock" ); 

} 

public void ejectMoney( PopMachine popMachine ) { 

System.out.printin( "no money to return" ); 

} 

public void dispense( PopMachine popMachine ) { 

System.out.printin( "machine out of stock" ); 

} 


Out Of 
Stock 
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D public class PopMachine { 



P 

P 

P 

P 

P 

P 


iivate State hasOneLoonieState; 
iivate State outOfStockState; 

iivate State currentState; 
iivate int count; 

i blic PopMachine( int count ) { 

// make the needed states 
startState = new StartState(); 
hasOneLoonieState = new HasOneLoonieState(); 
outOfStockState = new OutOfStockState(); 

if (count > 0) { 

currentState = startState; 
this.count = count; 

} else { 

currentState = outOfStockState; 
this.count = 0; 

} 
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delegate 

behavior 

to 

current 

state 


ublic void insertLoonie() { 

currentState.insertLoonie( this ); 


public void ejectMoneyO { 

currentState.ejectMoney( this 

} 

public void dispense() { 

currentState.dispense( this ); 

} 


pu 


blic void setState( State state 
currentState = state; 


) { 


public int getCount() { 
return count; 

} 


// getters for state objects, machine acti 


ons, etc. 


} 







Example Use and Output 

public static void main( String[] args ) { 

PopMachine popMachine = new PopMachine( 10 ) ; 

// usual scenario 

popMachine . insertLoonie () ; loonie inserted 

popMachine . dispense () ; releasing product 


} 

// popMachine.insertLoonie() delegates to 
// insertLoonie () method of current state object 
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State Pattern with Java enum 


enum State { 

// each value is an instance of a singleton 
START { }, 

HAS_ONE_LOONIE { }, 

OUT_OF_STOCK { }; 

public abstract 

void insertLoonie ( PopMachine popMachine ) ; 
public abstract 

void ejectMoney( PopMachine popMachine ); 
public abstract 

void dispense( PopMachine popMachine ); 


D enum State { 

START { 

public void insertLoonie ( PopMachine popMachine ) { 



System.out.printin( "loonie inserted" ); 


popMachine.setState( HAS_ONE_LOONIE ); 


} 


>ublic void ejectMoney( PopMachine popMachine ) { 

System.out.printin( "no money to return" ); 


} 

P 

} 


iblic void dispense( PopMachine popMachine ) { 

System.out.printin( "payment required" ); 


; r 

HAS._ONE_LOONIE { 


}, 

OUT 


OF_STOCK { 
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public class PopMachine { 



// no need to create state objects here 

private State currentState; 
private int count; 

public PopMachine ( int count ) { 

if (count > 0) { 

currentState = State.START; 
this.count = count; 

} else { 

currentState = State.OUT_OF_STOCK; 
this.count = 0; 

} 

} 

// the rest as before 
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State Pattern 


Design intent: 

“allow an object to alter its behavior when its internal state 
changes" 


simplify operations with long conditionals that depend on 
the object's state 
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State Structure 



object to alter behavior 

134 



























Decorator Pattern 
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Decorator Pattern 


Design intent: 

“attach additional responsibilities to an object dynamically" 
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Motivation 


Use: 

making user interface embellishments 

• e.g., dynamically adding "decorations" 
(menu bar, vertical scrollbar, horizontal 
scrollbar) to a basic window 


don't want too many new subclasses 


use aggregation instead of inheritance 


Handling Requests 

single component"transparent " enclosures 



v scrollbar 
decorator 


encloses 



menubar 

decorator 


encloses 



draw method: 

encl.draw(); 
draw itself 


this method 
should do 
everything this 
object “encloses” 
plus something 
extra 


draw method: 

encl.draw(); 
draw itself 


this method 
should do 
everything this 
object “encloses” 
plus something 
extra 


draw method: 

draw itself 
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"Transparent Enclosure" 

Idea: 

single-component aggregation/composition 


containing enclosure and contained component have 
compatible interfaces 


enclosure may partly delegate methods to component, and 
augment component behavior 
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MenuBarDecorator 


+draw() 


VScrollBarDecorator 


+draw() 


HScrollBarDecorator 


+draw() 
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ConcreteDecoratorl 


+operation() 


ConcreteDecoratorl 


+operation() 
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•° Chain of 
Responsibility 
Pattern 
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Handling Requests 



handle method: 

if (can handle) { 
handle request 
} else { 

next.handle(); 

} 


handle method: 

if (can handle) { 
handle request 
} else { 

next.handle(); 

} 


handle method: 

if (can handle) { 
handle request 

} 


request can be passed along and eventually handled by a 
handler (or not at all) 


this handler not known ahead of time by the request initiator 
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Chain of Responsibility Example 1 



handle method: 

if (matches) { 
do match action 
} else { 

next.handle(); 

} 


handle method: 

if (matches) { 
do match action 
} else { 

next.handle(); 

} 


handle method: 

if (matches) { 
do match action 

} 
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Chain of Responsibility Example 



print button 


npyf 



print dialog 


next 



application 



handle method: 

if (has help) { 
show print 
button help 
} else { 

next.handleQ; 


handle method: 

if (has help) { 
show print 
dialog help 
} else { 

next.handleQ; 


handle method: 

if (has help) { 
show 

application help 
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Chain of Responsibility Pattern 


Design intent: 

“avoid coupling the sender of a request to its receiver by 
giving more than one object a chance to handle the 
request" 


“chain the receiving objects and pass the request along the 
chain until an object handles it“ 
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next 
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Consequences 

Reduces coupling: 

frees an object from knowing which other object handles 
request 


sender and receiver do not have direct knowledge about 
each other 


Design Principles 


Design Principles 

Goals: 

enhance flexibility under changing needs 
improve reusability in different contexts 


Note: 

need balanced use of these guidelines 


don't overuse 


Open Closed Principle 

"Classes should be open for extension, but closed for 
modification." 


Yes, we are ... 

OPEN 


feel free to extend the 
classes and add new classes 
when needs change 


d 




Sorry, we are ... 

CLOSED 


existing classes are tested 
and work, so do not tinker 
with them 
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Open Closed Principle 

"Encapsulate what varies." 

separate and isolate into an object 


varying part 


stable part 


varying part 


likely to change 


stable part 


use in 
Decorator > 
Template Method, 
Factory , 

State patterns 
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Open Closed Principle 

What parts of a system are likely to vary? 
hardware dependencies 

business rules 

input and output formats 

user interface 

challenging design areas 

algorithms 

data structures 
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Dependency Inversion Principle 


“Depend upon abstractions. Do not depend on concrete 
classes." 


Consumer 



ncreteResource 


in procedural programming , 
high-level modules depend 
on low-level modules 


in object-oriented design , 
high-level classes refer to 
abstractions , and low-level 
classes depend upon these 
abstractions 
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Dependency Inversion Principle 


“Depend upon abstractions. Do not depend on concrete 
classes." 


abstract class 



can plug in alternatives 
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Dependency Inversion Principle 

“Program to interfaces, not implementations." 
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Composing Objects 

"Favor composing objects over implementation inheritance. 


tight coupling 


ArrayList 



Stack 


GoF believe 

designers 

overuse 

implementation 

inheritance 
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Composing Objects 

"Favor composing objects over implementation inheritance. 



UML association , aggregation , 
or composition 


striving for loose coupling 
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Composing Objects 

Implementation inheritance: 
compile-time dependency 

white-box reuse of superclass 

tight coupling, limits reuse of only subclass 


Composing objects: 

run-time dependency (e.g., via injection) 

black-box “arms length" reuse via well defined interfaces 

delegation 
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Composing Objects 

Delegation technique: 



delegates to 


receiving object forwards to delegate object 







Principle of Least Knowledge 


"Only talk to your immediate friends." 

for an object, reduce the number of classes it knows about 
and interacts with 


reduces coupling and changes cascading throughout the 
system 


161 


Principle of Least Knowledge 


"Law of Demeter": 

for method M of object O, 

only call methods of the following objects 

• object O itself 

• parameters of method M 

• any objects instantiated within method M 

• direct component objects of object O 


Principle of Least Knowledge 


"Law of Demeter": 

avoid calling methods of objects returned by other 
methods (unless allowed by the law) 


// couples this method to Preference class 
Preference pref = user.getPreference(); 
pref.doSomething(); 


// equivalently 

user.getPreference().doSomething(); 


i.e., "one dot only rule" 


More Information 


Books: 

Head First Design Patterns 

• E. Freeman, E. Robson, B. Bates, and K. Sierra 

• O'Reilly, 2004 
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More Information 


Books: 

Design Patterns 

• E. Gamma, R. Helm, R. Johnson, and J. Vlissides 

• Addison-Wesley, 1995 

Patterns in Java 

• M. Grand 

• Wiley, 1998 
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More Information 


Links: 

Source Making Design Patterns 

• http://sourcemaking.com/design_patterns 


Vince Huston Design Patterns 




http://www.vincehuston.org/dp/ 


More Information 


Links: 

Speaking on the Observer Pattern 

• http://www.javaworld.com/javaqa 
/2001-05/04-qa-0525-observer.html 


Learn How to Implement the Command Pattern in Java 

• http://www.javaworld.com/javatips 
/jw-javatip68.html 
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More Information 


Links: 

Design Principles and Design Patterns 

• http://www.objectmentor.com/resources/articles/ 
Principles_and_Patterns.pdf 


Law of Demeter 

• http://www.ccs.neu.edu/home/lieber/LoD.html 


Portland Pattern Repository 

• http://c2.com/ppr/ 
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